Resource allocation in packet network

ABSTRACT

The idea of the invention is to negotiate the resource allocation between two network elements on the Application or Transport layer level so that the negotiation is possible over the network, even if the network comprises several physically different networks. To determine the transmission capacity for the allocation, the sending element must first send a request message with a proposal for the capacity and media types. The receiving element either accepts the proposal or makes a new proposal by changing the parameter values so that they are acceptable from the point of view of the receiver, and sends a response to the sending element. Based on the response from the receiving element, the sending element the either accepts or rejects the allocation and informs the receiving element of its decision by sending a confirmation.

FIELD OF THE INVENTION

This invention relates to resource allocation in packet switchingnetworks, especially in IP networks.

BACKGROUND OF THE INVENTION

The tasks of a network are divided into several entities, called layers,that handle specified tasks. For example, it is possible to separatefour distinct layers in IP networks: the Link, Network, Transport andApplication layer (FIG. 1). In known IP networks signaling handlesmainly channel related matters, such as connection set up and connectionbreak off, while management handles element configuration, monitoring,and error messages, for example.

The Network layer is the heart of the IP network. It specifies theformat of the Internet packets, called datagrams. Datagrams containspecified fields, such as the destination and the source of the datagrampacket. Information is sent by packets which contain the information forrouting the packet to the right destination element. The routers in thenetwork must know how to route the packets to the right receiver, so theIP layer also includes a set of rules defining how the packets should beprocessed.

The Transport layer specifies means for identifying the ultimatedestination, i.e. the application in the receiving network element. Thetwo most common ways to handle the transport of a packet are UDP (UserDatagram Protocol) and TCP (Transmission Control Protocol). UDP is anunreliable connectionless delivery system, while TCP provides reliabledelivery. That means that the TCP sender and receiver must agree that aconnection is desired. TCP requires an acknowledgment message from thereceiver before the sender is allowed to send more packets. TCP uses asliding window technique to send acknowledgments. The sliding windowindicates the number of packets that a sender can send without receivingan acknowledgment. When the sender gets the acknowledgment concerningthe first packet sent, the window slides, making it possible to send anew packet. The receiver can advise the sender what the preferable sizefor the sliding window is (specifying the receiver's current buffersize). In other words, the sliding window technique can be used for flowcontrol.

The Application layer handles a variety of tasks, such as e-mail andfile transport. This layer also contains SNMP (Simple Network ManagementProtocol) that handles matters such as configuration of network elementsand monitoring.

The Link layer consists of a physical network, such as Ethernet and ATM.In ATM networks, for example, it is possible to group several virtualchannels together into a virtual path, that is an individual manageableobject.

The disadvantage of the known solutions is that there is no common wayto handle the allocation of network resources in a packet network, suchas an IP network. Known resource allocations are dependent on networkcharacteristics, and thus run on the Link layer. In other words,resource allocation is possible only in the same physical network, suchas ATM, but it is impossible to negotiate resource allocation betweentwo network elements in different networks using one common environment.Due to the lack of a common resource allocation method, it iscomplicated to agree on traffic allocation, for example betweenoperators. Dynamic allocation can also be tedious. The objective of theinvention is to eliminate these disadvantages. This is achieved in a waydescribed in the claims.

SUMMARY OF THE INVENTION

The idea of the invention is to negotiate the resource allocationbetween two network elements on the Application or Transport layer levelso that the negotiation is possible over the network, even if thenetwork comprises several physically different networks. To determinethe transmission capacity for the allocation, the sending element mustfirst send a request message with a proposal for the capacity and mediatypes. The receiving element either accepts the proposal or makes a newproposal by changing the parameter values so that they are acceptablefrom the point of view of the receiver, and sends a response to thesending element. Based on the response from the receiving element, thesending element the either accepts or rejects the allocation and informsthe receiving element of its decision by sending a confirmation.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following the invention is described in more detail by means ofFIGS. 2-7 in the attached drawings, where

FIG. 1 illustrates layers of a packet switching network,

FIG. 2 illustrates a capacity allocation according to the invention,

FIG. 3 depicts a capacity allocation request according to the invention,

FIG. 4 depicts a response for the capacity allocation request accordingto the invention,

FIG. 5 depicts a pending message according to the invention,

FIG. 6 depicts a release of the resource allocation according to theinvention.

FIG. 7 illustrates a time-out for a request.

DETAILED DESCRIPTION OF THE INVENTION

A communication network consists of many different elements, such asexchanges and switches in traditional PSTN networks, base stations andmobile switching centers in mobile networks, and bridges and routers indatacommunication networks. Networks also contain data and signalingchannels between the different elements. A packet switching IP networkis more like a virtual network, which is built over several physicalnetworks.

Resource allocation involves a transmission capacity agreement betweentwo network elements. The transmission capacity agreement can contain,for example, the number of channels to be used, the type of the channels(audio, data, fax, etc.) and the bandwidth of the channels. Generally,existing technology does not include a way to negotiate resourceallocation between different network elements over a variety ofdifferent networks. In order that resource allocation is possible in apacket network, there must be a common way to negotiate allocations.

FIG. 2 depicts an example of a packet switching virtual network (IPnetwork). The virtual network can contain many subnetworks, but becausethe virtual network forms a common way for transmission, it isreasonable to picture the network as one entity. The virtual network canhave connections to other networks, such as PSTN. In this context, it isalso reasonable to name the network elements in a uniform way. Let'scall the elements endpoints. In real physical networks endpoints areexchanges, routers, switching centers, etc.

FIG. 2 shows an example of how a negotiation of the resource allocationbetween endpoint 1 and endpoint 2 is made according to the invention.The goal is to agree on the biggest possible traffic capacity betweenthe endpoints. The negotiation channel between the endpoints ispreferably formed by signaling channels in the IP network. The networkhandles routing of the signaling, and it is not a part of the invention.An endpoint is responsible for handling certain traffic capacity needsfrom the part of the network that is connected to the endpoint (forexample a local exchange). The endpoint can also be responsible forhandling by-pass traffic (for example a router). FIG. 2 depicts thesituation where endpoint 1 and endpoint 2 handle the traffic of theirrespective subnetworks. The negotiation between endpoints 1 and 2 startswhen endpoint 1 sends a request for capacity needs. The request containsthe number of different channel types required, for example 500 audiochannels, 500 data channels and 300 fax channels. Endpoint 2 receivesthe request and compares it to it's own resources. If endpoint 2 hasenough capacity to handle the amount requested, it accepts the requestand sends back a proposal with the same capacity values. If endpoint 2does not accept the request, it processes the maximum acceptable valuesthat are still smaller than the values in the request, for example 300audio channels, 200 data channels and 100 fax channels, and sends theproposal with new values back to endpoint 1. Endpoint 1 receives theproposal, makes a decision on the acceptability of the resourceallocation, and sends a confirmation comprising the decision to endpoint2.

The function of the negotiation process according to the invention canbe divided into two mandatory portions: Initial Negotiation andRe-negotiation, and two optional portions: Pending Option and RemovingOption.

The Initial Negotiation includes the request, the response, and theconfirmation as described above. The format of the request is depictedin FIG. 3. The request, like the other messages according to theinvention as well, is sent over TCP or UDP, i.e. in the data field ofthese protocols. Version (4 bits) is a model version of the format.Version makes an adaptation possible between different updated modelversions. Message (8 bits) identifies the message and allows fastinterpretation of the message content. Length (2 octets) tells thelength of the message in octets. Reservation (4 bits) is reserved forfuture use. Initial Token (4 octets) identifies the sender who hasinitialized the request. Initial Ticket (4 octets) is a parameter thatis set by the sender. The receiver records the value of the InitialTicket. The meaning of the Initial Ticket is to identify thenegotiation. Media Type identifies the desired media type, i.e. audio,video, fax, or data. Media Property (2 octets) tells the bandwidthneeded for the media type. Tariff (1 octet) contains tariff informationrelated to capacity reservation. Capacity (4 octets) tells the capacityreserved in units of media used (number of channels). Time for Validityis the time value indicating how long the negotiated capacity is valid.Media Type and Capacity are mandatory fields, whereas Media Property,Tariff, and Time for Validity are optional fields.

Response (FIG. 4) contains the same fields as the request format exceptthat Initial Token is replaced by Response Token, and there is a newfield: Second Party Ticket. The Response Token identifies the sender ofthe initial request. The Second Party Ticket is set by the receiver andrecorded by the sender of the initial request. The Second Party Ticketidentifies the capacity negotiation, and it is used for furthernegotiation to change the resource allocation. The Capacity remains thesame as in the Request if the receiver accepts it, otherwise thereceiver uses it's own values.

The format of the confirmation is the same as the format of theresponse. The sender of the initial request sends the confirmation tothe receiver with parameters copied from the response. If the senderdoes not accept the values set by the receiver, it can refill theCapacity parameters to zero value indicating that the negotiation wasunsuccessful. Later on, if needed, the sender can initialize a newnegotiation.

Re-negotiation is used when either one of the endpoints wants to changethe Capacity parameters. The endpoint that starts the negotiation mustset Initial Ticket and Response Token to the same values as used in theinitial negotiation, otherwise messages are silently discarded. Thenegotiation progresses the same way as in the initial negotiation.

Pending is an optional feature (FIG. 7) and it makes it possible toinform the initial sender of the request that the request is underprocess, and Response will be returned before the indicated time-out. Inother words, Pending tells the time-out for the Request. The receiversends Pending after receiving Request, but before sending Response. FIG.5 depicts the format of Pending. A new field is Time for Pending. It isthe time value for how long the delay in responding is supposed to last.The rest of the fields are the same as described above: Version,Message, Length, Reservation, Response Token, Initial Ticket, and SecondParty Ticket.

Removing is also an optional feature, and it is used when one of theendpoints wants to remove the capacity reserved between the endpoints.The format of Removing is depicted in FIG. 6. There is one newparameter, Time for Release. The other parameters are familiar from theabove. Time for Release is the time-out value that is needed before theresources negotiated are available. The removing function consists oftwo messages: Release and Release Acknowledged. The endpoint that startsRemoving sends a Release message to the other endpoint. The InitialTicket and Response Ticket fields in the release message are in the samevalues as in the initial negotiation, otherwise the message isdiscarded. The other endpoint sends back a Release Acknowledged messagewhich does not include Time for Release information.

Table 1 collects the different messages together. Table 2 describes thedifferent parameters.

TABLE 1 Messages Message Identifier Message Description 0x1 RequestInitial request for Capacity 0x2 Response Acknowledgment for initialrequest 0x3 Confirm Final confirmation of the Request 0x4 PendingIndicates that the Request is being processed and the handling of theRequest may takes longer than usual. 0x5 Release Releases reservation ofcapacity immediately or delayed, according of the Time for Validityparameter 0x6 Release Confirms the Release operation proposed by Ack.other endpoint. Parameter Description Version (4 bits) Protocol versiontells the updated version of the protocol. Message (8 octet) Messageidentifier identifies type of message. Length (2 octets) Tells Length ofMessage in octets starting from header. Reserved (4 bits) A fieldreserved for future use. Initial Token (4 Identifies origin of the partywhich has initialized octets) request Response Token (4 Identifiesorigin of the party which has initialized octets) response InitialTicket (4 Identifies capacity negotiation request and octets) is usedwith further negotiations in later if original values are changed.2^(nd) Party Ticket (4 Identifies capacity negotiation for 2^(nd) partyit is used octets) with further negotiations by initiated 2^(nd) partyif original values are changed. Media Type (1 Identifies the Media type.Possible values are Audio, octet) Video, Fax or Data Media Property (2This field gives more detailed information of octets) bandwith neededfor media type. Tariff (1 octet) The parameter tells tariff informationrelated to the reserved media package. Capacity (4 octets) Parametertells capacity reserved for Media units i.e. number of calls, ports orconnections. Time for Validity (4 The time value in seconds for how longthe octets) negotiated capacity is valid. Time for Pending The timevalue in seconds for how long pending is (4 octets) estimated to last.Time for Release The time value in seconds for how long the (4 octets)negotiated capacity is available.

The invention makes it possible to negotiate resource allocation betweentwo endpoints over a network, comprised of several physically differentnetworks. Routing is made as before in a packet switching network, butnow there is a negotiation for the resource allocation. The benefits ofthe negotiation are that it makes transmission more certain, makes itpossible to direct transmission traffic, and especially makes one commonway for handling negotiations, although there can be several differentphysical networks between the endpoints.

An endpoint handles transmission capacity as one pool from where it ispossible to make reservations for traffic to a certain endpoint, and sothe traffic load is easier to divide evenly to different directions.Resource allocations can be changed dynamically, thus an endpoint canadapt easily to different situations, such as more telephone calls inevenings, special services like telephone calls to a popular TV show,and a company's needs to transmit huge amounts of data during the daytime. The invention also makes it possible to negotiate resourceallocation between two operators. In this situation a SLA (Service LevelAgreement) is needed between the operators.

The situation in FIG. 2 where there is a negotiation for resourceallocation between endpoint 1 and endpoint 2, it can be done with onenegotiation for all media types. The Length field in message packetstells the total length of the negotiation message. In other words, data,audio, and fax types have their own message packets inside thenegotiation message, such as a Request message. The bandwidth of a mediatype can be determinated in the Media Property field. Consequently, thetotal bandwidth needed for an allocation is the bandwidth of a mediatype multiplied by the value of the Capacity field. The invention isespecially useful when the negotiation concerns huge amount of channels.

The invention is described above at the Application layer level, but itis clear that the invention can be implemented at the Transport layerlevel as well. The invention can be combined with other protocols aswell. For example, tunneling over H. 323, Q.BICC, and SIGTRAN arepossible by embedding the resource allocation information into thepayload information. Although the invention is described more like aseparate protocol, it can be integrated as a portion of anotherprotocol. It is evident that the invention is not restricted to theabove-mentioned examples, but that it can be used in otherimplementations within the scope of the inventive idea.

1. A method for allocating transmission resources between first andsecond network elements, the method comprising: sending a requestmessage, from the first network element to the second network element,the request message including a value of a capacity that the firstelement desires to allocate for use between the two network elements,receiving the request message in the second network element and findinga capacity value which is acceptable from the point of view of thesecond network element and not greater than the value received in therequest message, sending a response message from the second networkelement to the first network element, the response message including thecapacity value found in the second network element, receiving theresponse message in the first network element and making a decision,based on the capacity value received in the response message, on theacceptability of the resource allocation, and sending a confirmationmessage from the first network element to the second network element,the confirmation message including data indicating the decision made,wherein the first and second network elements are in a packet switchingnetwork comprising physically different networks, the first networkelement being the sending network element, wherein the resources areallocated by exchanging messages above a network layer between the firstand second network elements, wherein the request message furtherincludes a type of the capacity, a token for identifying the request, abandwidth of the type of the capacity, tariff information related to thecapacity, and time information indicating how long the resourceallocation is to be valid.
 2. A method according to claim 1, wherein theresponse message further includes: a type of the capacity to beallocated for use, a token for identifying the request, and a token foridentifying the allocation session.
 3. A method according to claim 2,wherein the response message further includes: a bandwidth of the typeof the capacity, tariff information related to the capacity to beallocated for use, and time information indicating how long the resourceallocation is to be valid.
 4. A method according to claim 1, wherein theconfirmation message includes: a type of the capacity to be allocatedfor use, the accepted value, a token for identifying the request, and atoken for identifying a resource allocation session.
 5. A methodaccording to claim 4, wherein the confirmation message further includes:a bandwidth of the type of the capacity, tariff information related tothe capacity to be allocated for use, and time information indicatinghow long the resource allocation is valid.
 6. A method according toclaim 1, wherein before sending the response message, the second networkelement sends a pending message to the first network element, thepending message including: a token for identifying the request, a tokenfor identifying an allocation session, and time information indicating amaximum time period between the request message and the responsemessage.
 7. A method according to claim 1, wherein the method furtherincludes: sending a release message from one network element to theother network element for releasing the resource allocation, sending arelease-acknowledged-message from the network element that received therelease message to the network element that sent the release message. 8.A method according to claim 7, wherein the release message includes: atoken for identifying the request, a token for identifying the resourceallocation session, and time information for indicating how long theresource allocation is available.
 9. A system, comprising: a firstnetwork element configured to send a request message and a proposalcapacity; a second network element configured to receive the proposalfor capacity, and transmit a response to the first network element,wherein the first network element is further configured to receive theresponse and to make a decision based on the received response, ofacceptability of resource allocation, and wherein the first networkelement is further configured to transmit a confirmation message to thesecond network element, wherein the request message further includes atype of the capacity, a token for identifying the request, a bandwidthof the type of the capacity, tariff information related to the capacity,and time information indicating how long the resource allocation is tobe valid.
 10. The system according to claim 9, wherein the responsemessage further includes: a type of the capacity to be allocated foruse, a token for identifying the request, and a token for identifying anallocation session.
 11. The system according to claim 10, wherein theresponse message further includes: a bandwidth of the type of thecapacity, tariff information related to the capacity to be allocated foruse, and time information indicating how long the resource allocation isto be valid.
 12. The system according to claim 9, wherein theconfirmation message includes: a type of the capacity to be allocatedfor use, an accepted value of the resource allocation, a token foridentifying the request, and a token for identifying the allocationsession.
 13. The system according to claim 12, wherein the confirmationmessage further includes: a bandwidth of the type of the capacity,tariff information related to the capacity to be allocated for use, andtime information indicating how long the resource allocation is valid.14. The system according to claim 9, wherein before sending the responsemessage, the second network element sends a pending message to the firstnetwork element, the pending message including a token for identifyingthe request, a token for identifying an allocation session, and timeinformation indicating the maximum time period between the requestmessage and the response message.
 15. The system according to claim 9,wherein the first network element is configured to send a releasemessage from one network element to the other network element forreleasing the resource allocation, and the second network element isconfigured to send a release-acknowledged-message to the first networkelement.
 16. The system according to claim 15, wherein the releasemessage includes: a token for identifying the request, a token foridentifying an allocation session, and time information for indicatinghow long the resource allocation is available.
 17. A system, comprising:a first network means for sending a request message and a proposalcapacity; a second network means for receiving the proposal forcapacity, and transmitting a response to the first network element,wherein the first network means is further configured for receiving theresponse and for making a decision based on the received response, ofacceptability of resource allocation, and wherein the first networkmeans is further configured for transmitting a confirmation message tothe second network element wherein the request message further includesa type of the capacity, a token for identifying the request, a bandwidthof the type of the capacity, tariff information related to the capacity,and time information indicating how long the resource allocation is tobe valid.